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Abstract 


A  portable  operating  system  is  an  operating  system  that  can  be  easily  tran¬ 
sported  to  different  computer  architectures.  This  thesis  will  examine  some 
machine  dependencies  of  operating  systems,  and  methods  of  isolating  the 
machine  dependencies  into  separate  modules.  Rewriting  these  machine  depen¬ 
dent  modules  for  a  new  machine  allows  the  operating  system  to  be  moved  to  that 
machine.  TUNIS,  a  UNIX-like  operating  system,  is  presented  as  a  prime  example 
of  a  portable  operating  system. 
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CHAPTER  1 


Introduction 


1.1.  Portable  Operating  Systems 

An  operating  system  is  an  organized  collection  of  programs  that  act  as  an  inter¬ 
face  between  machine  hardware  and  users,  providing  users  with  a  set  of  facili¬ 
ties  to  simplify  the  design,  debugging,  and  maintenance  of  programs;  and,  at  the 
same  time,  controlling  the  allocation  of  resources  to  assure  efficient  operation 
[Shaw  pages  1-2] 

A  portable  operating  system  is  an  operating  system  that  can  be  easily  tran¬ 
sported  to  different  computer  architectures.  There  have  been  few  portable 
operating  systems  in  the  past,  as  most  operating  systems  were  designed  for  one 
particular  computer,  or  computer  family,  and  cannot  be  easily  moved  to  other 
computer  architectures. 

Portable  operating  systems  provide  a  uniform  working  environment  across 
many  machines,  reducing  the  machine-specific  interfaces  that  a  user  must  face. 
A  portable  operating  system  has  a  similar  user  level  interface  over  all  machines, 
allowing  easy  transportation  of  programs  and  algorithms.  An  operating  system 
that  can  be  easily  transported  aids  in  the  deployment  of  new  machines  and  archi¬ 
tectures  by  quickly  providing  an  operating  system  and  many  useful  programs  for 
the  new  machine.  This  leads  to  a  large  user  community  using  the  same  operating 
system,  and  generates  a  large  database  of  programs  that  can  be  shared  between 
users  on  different  machines. 

A  portable  operating  system  should  be  able  to  support  a  new  computer  archi¬ 
tecture  with  a  minimum  of  changes  to  the  operating  system  itself.  It  allows  new 
Input/Output  (I/O)  devices  to  be  easily  added,  and  the  number  of  I/O  devices  to 
be  easily  modified  to  support  any  system  reconfiguration.  The  operating  system 
should  be  well  documented  and  easy  to  maintain,  while  at  the  same  time,  it  must 
be  sufficiently  general  purpose  so  that  it  can  be  used  for  a  rich  class  of 
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applications. 


1.1.1.  Organization  of  the  Thesis 

Chapter  one  discusses  general  techniques  for  designing  portable  operating 
systems.  Chapter  two  briefly  examines  other  operating  systems  for  small  com¬ 
puter  systems  (microcomputers  and  minicomputers)  that  have  been  transported 
to  several  architectures.  In  Chapter  three,  the  structure  of  TUNIS  is  discussed 
and  the  programming  language  Concurrent  Euclid,  in  which  TUNIS  is  written,  is 
introduced.  Chapters  four  and  five  examine  the  hardware  and  the  modules  con¬ 
trolling  the  hardware,  emphasising  the  solutions  to  portability  problems  that  are 
used  in  TUNIS  .  Chapters  six  and  seven  examine  the  portability  of  the  file  system 
and  interfacing  to  user  programs.  Chapter  eight  gives  a  brief  review  of  the 
current  state  of  TUNIS. 

1.1.2.  Goals  of  the  TUNIS  project 

There  were  many  goals  in  the  TUNIS  project: 

(1)  Could  a  production  quality  operating  system  be  written  in  a  high  level 
language  with  concurrency  support? 

(2)  Would  this  highly  structured  operating  system  with  processes  and  monitors 
cause  serious  problems  with  system  performance? 

(3)  What  parts  of  an  operating  system  are  machine  and  device  dependent?  How 
can  these  sections  be  made  more  machine  independent? 

(4)  Is  the  language  Concurrent  Euclid,  developed  for  the  TUNIS  project,  well 
suited  for  this  purpose? 

It  was  decided  to  use  the  specifications  of  an  existing  operating  system, 
instead  of  developing  a  new  user-level  interface.  This  allowed  existing  software 
to  be  used  in  the  testing  process,  and  gave  a  system  that  could  easily  be  com¬ 
pared  to  the  original  operating  system. 
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(5)  Could  we  rewrite  the  UNIX  operating  system  in  a  structured  language  with 
monitors?  The  existing  UNIX  implementations  are  not  well  structured. 

(6)  Can  TUNIS  be  specified,  and  could  we  verify  the  implementation  of  TUNIS 
meets  these  specifications? 

1.2.  Techniques  Used  to  Aid  Portability 

The  desired  functions  of  an  operating  system  should  be  well  defined  and 
specified.  These  specifications  will  be  used  to  design  and  understand  the  operat¬ 
ing  system,  and  allow  the  implementors  to  verify  that  the  operating  system  per¬ 
forms  up  to  the  specifications.  For  an  operating  system,  the  specifications  con¬ 
sist  of  the  system  call  interface. 

For  a  portable  operating  system,  a  programming  language  whose  semantics 
are  defined  in  a  machine  independent  manner  removes  the  possibility  of  using 
machine  dependent  features  of  the  language.  The  portability  of  the  operating 
system  is  then  ensured  by  the  portability  of  the  compiler  of  the  language. 

A  portable  operating  system  should  be  written  in  a  language  that  includes 
concurrency  support,  because  operating  systems  are  generally  concurrent  pro¬ 
grams,  and  easy  access  to  machine  hardware,  because  an  operating  system  must 
control  the  I/O  devices  on  the  computer  system.  Access  to  the  hardware  from  a 
high  level  language  will  maximize  the  proportion  of  the  operating  system  that  will 
be  written  in  the  high  level  language.  Some  assembly  language  routines  may  be 
necessary  to  perform  functions  that  cannot  be  done  at  a  higher  level.  This  is 
because  the  hardware  attached  to  the  system  must  be  made  to  operate  in  a  stan¬ 
dard  way,  the  way  that  the  higher  levels  of  the  operating  system  expects  it  to  act. 
The  assembly  language  routines  will  allow  the  upper  levels  of  the  system  to  pre¬ 
tend  that  the  I/O  device  is  more  intelligent  than  it  actually  is. 

The  implementation  language  should  be  a  strongly  typed  language  to 
inerease  the  amount  of  checking  that  can  be  performed  by  the  compiler.  This 
checking  will  reduce  the  possibility  of  making  certain  errors  in  the 
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implementation  of  an  operating  system,  and  will  help  in  the  debugging  of  the 
operating  system. 

The  Toronto  UNIversity  System  (TUNIS)  is  written  in  Concurrent  Euclid 
[Cordy,  Holt],  a  language  of  the  Euclid  family  [Lampson,  Popek].  Concurrent 
Euclid  supports  all  the  features  desirable  to  a  portable  operating  system.  It  is  a 
highly  structured,  strongly  typed  language  with  concurrency  support. 

1 .3.  Operating  System  Structure 

The  TUNIS  operating  system  is  based  on  the  hierarchical  structure  of  the 
THE  operating  system  [Dijkstra].  The  operating  system  is  organized  into  func¬ 
tional  layers,  with  each  layer  defining  a  abstract  machine  with  more  operations. 
This  allows  the  upper  layers  to  use  the  facilities  of  the  immediately  lower  level  in 
their  functions.  For  example,  if  one  layer  supports  file  operations,  then  higher 
layers  can  use  these  functions  to  read  and  write  files  as  necessary.  The  lowest 
layer  of  the  operating  system  is  the  hardware,  the  highest  layer  is  the  interface 
to  user  programs. 

Another  benefit  to  a  hierarchical  design  is  that  it  is  possible  to  verify  the 
implementation  of  each  layer  of  the  operating  system  without  referring  to  the 
implementation  of  other  layers  of  the  system.  The  hierarchical  structure  aids  in 
the  testing  and  debugging  of  the  operating  system,  because  each  layer  can  be 
tested  thoroughly  before  the  next  layer  of  the  system.  This  allows  path  testing 
(testing  every  path  through  a  program)  to  be  performed  very  easily.  It  is  harder 
to  path  test  a  non-structured  operating  system,  because  the  system  must  be 
tested  as  a  whole,  and  the  testing  programs  must  path  test  the  entire  operating 
system  at  one  time.  It  is  easier  to  write  the  path  testing  programs  for  a  struc¬ 
tured  system,  because  there  are  fewer  paths  to  test  at  each  level.  This  increases 
the  confidence  that  the  operating  system  is  a  correct  implementation. 

TUNIS  is  written  in  a  highly  structured  language,  organized  into  software 
modules  corresponding  to  the  layers  of  the  operating  system.  Each  module  has 
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well  defined  semantics  and  interfaces  to  the  other  modules  in  the  system.  This 
allows  changes  to  be  made  to  the  internal  functions  of  a  module  without  affecting 
the  rest  of  the  operating  system,  if  the  specifications  of  the  module  are  not 
changed.  Modules  can  also  be  understood  and  verified  without  the  need  to  under¬ 
stand  the  internals  of  modules  that  are  referenced. 

Within  each  module  in  the  lower  layers  of  TUNIS,  the  routines  that  are 
machine  or  device  dependent  are  collected  within  smaller  machine  dependent 
modules.  This  eases  the  transportation  of  the  operating  system  to  a  new  archi¬ 
tecture  by  marking  the  portions  of  the  system  that  must  be  examined  and 
changed.  All  other  modules  in  the  operating  system  are  machine  independent, 
and  do  not  have  to  be  modified  when  transporting  the  operating  system.  The 
machine  dependent  routines  will  usually  appear  in  the  modules  that  deal  with  I/O 
device  control,  memory  management  hardware,  and  the  interface  between  the 
operating  system  and  user  programs. 
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CHAPTER  2 


Introduction  to  TUNIS 

This  chapter  describes  the  TUNIS  operating  system.  The  history  of  TUNIS  is 
sketched.  Concurrent  Euclid,  the  implementation  language  for  TUNIS  is  intro¬ 
duced,  and  the  concurrency  mechanisms  of  Concurrent  Euclid  are  described.  The 
structure  of  TUNIS  is  examined. 

2.1.  TUNIS 

TUNIS  is  an  implementation  of  the  user  level  interface  to  the  UNIX  operating 
system.  It  is  a  structured  version  of  the  UNIX  kernel,  using  processes  and  moni¬ 
tors  for  concurrency. 

2.1.1.  History  of  TUNIS 

TUNIS  has  its  roots  in  a  project  for  a  graduate  course  in  operating  systems. 
The  goal  of  the  project  was  to  design  and  implement  a  highly  structured  version 
of  UNIX  using  Euclid  and  monitors.  This  led  to  the  design  of  Concurrent  Euclid 
during  1980-81  from  the  experience  gained  from  the  TUNIS  project.  In  1980, 
Patrick  Cardozo  [Cardozo]  implemented  the  lower  layers  of  TUNIS  on  a  PDP 
11/23.  In  1981,  the  next  year  of  the  graduate  course,  TUNIS  was  redesigned  and 
rewritten  to  use  Concurrent  Euclid.  TUNIS  was  initially  targeted  for  the  PDP 
11/23  and  the  Motorola  MC68000  architectures. 

During  1981,  the  design  of  TUNIS  was  redefined  and  implemented  by  Profes¬ 
sor  R.  Holt,  Professor  D.  Barnard,  and  the  author.  The  Memory  module  was 
designed  by  Professor  Holt,  the  Flat  File  module  by  Professor  Barnard,  and  the 
remainder  of  the  system  was  rewritten,  debugged,  and  tested  on  the  PDP  11/23 
by  the  author.  By  December  1981,  TUNIS  was  almost  completely  implemented  on 
the  PDP  11/23. 
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TUNIS  is  a  subset  of  UNIX  version  7,  and  uses  the  same  disk  file  system  and 
the  same  user  interface  to  the  operating  system.  Object  modules  from  UNIX  will 
run  unchanged  (with  a  few  exceptions)  on  TUNIS.  TUNIS  was  developed  to  be  a 
portable  operating  system  suitable  for  a  general  purpose  operating  system,  as 
well  as  a  stand-alone  microprocessor  system. 

2.1.2.  Concurrent  Euclid 

Euclid  was  designed  in  1976  as  a  language  for  developing  verifiable  system 
software.  Use  of  Toronto  Euclid,  a  subset  of  full  Euclid  developed  jointly  by  the 
University  of  Toronto  and  I.  P.  Sharp  Associates,  and  the  initial  design  of  the 
TUNIS  project  led  to  the  design  and  implementation  of  Concurrent  Euclid  in 
1980-81.  Concurrent  Euclid  omits  the  more  complex  features  of  Euclid,  and  added 
features  not  in  Toronto  Euclid  that  were  found  necessary  for  systems  program¬ 
ming.  These  include  concurrency  and  separate  compilation. 

Concurrent  Euclid  inherited  constructs  designed  for  verification  of  software 
from  Euclid.  These  include  modules,  a  syntactic  construct  for  packaging  data 
together  with  the  procedures  and  functions  that  access  the  data,  and  explicit 
control  of  the  scope  of  types  and  variables  through  import  and  export  lists.  Con¬ 
current  Euclid  also  includes  long  (32-bit)  arithmetic,  variables  at  absolute 
memory  locations,  and  escape  mechanisms  to  defeat  compile  time  type  checking. 

The  major  enhancement  to  Concurrent  Euclid  is  the  inclusion  of  concurrency 
in  the  language.  Concurrent  Euclid  supports  multiple  processes,  and  monitors 
[Hoare]  to  implement  inter-process  communications.  Monitors  are  a  form  of 
modules  that  allow  only  one  process  to  be  active  within  the  monitor  at  a  time. 
This  protects  shared  data  from  the  corruption  that  may  result  from  simultaneous 
updates  by  multiple  processes.  A  process  wishing  to  enter  a  monitor  will  be 
blocked  at  the  entrance  of  the  monitor  until  there  are  no  processes  active  within 
the  monitor. 
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Monitors  also  provide  synchronization  between  processes  through  the  use  of 
conditions.  A  process  within  a  monitor  may  block  itself  by  performing  a  wait  on 
a  condition.  This  blocks  the  process  on  that  condition  and  removes  the  process 
from  the  monitor,  allowing  other  processes  to  enter  the  monitor.  A  waiting  pro¬ 
cess  may  be  unblocked  by  the  use  of  the  signal  statement.  If  there  is  a  process 
blocked  on  the  condition,  the  signalling  process  temporarily  steps  out  of  the  mon¬ 
itor,  allowing  the  signalled  process  to  execute.  Conditions  guarantee  that  the 
order  of  resumption  of  waiting  processes  is  fair.  The  signaling  process  will  con¬ 
tinue  execution  when  there  are  no  processes  in  the  monitor.  Priority  conditions 
allow  specification  of  the  order  that  waiting  processes  will  be  signalled. 

2.2.  Structure  of  TUNIS 

TUNIS  has  a  hierarchical  structure  consisting  of  five  major  layers  [see  figure 
l].  The  implementation  of  each  layer  consist  of  one  or  more  Concurrent  Euclid 
modules.  All  modules  except  the  kernel  are  written  entirely  in  Concurrent  Euclid. 
TUNIS  has  been  divided  into  these  layers  to  separate  and  emphasize  the  functions 
of  the  operating  system.  TUNIS  consists  of  eleven  Concurrent  Euclid  modules  and 
the  kernel,  each  module  providing  a  layer  of  abstraction  on  which  higher  layers 
are  based.  These  modules  are  implemented  in  Concurrent  Euclid,  so  the  compiler 
will  guarantee  that  internal  details  of  each  module  are  hidden  from  other 
modules.  Logically  independent  functions  in  TUNIS  are  structurally  independent 
as  well.  This  enables  TUNIS  to  isolate  the  machine  dependencies  to  as  few 
modules  as  possible. 


-8- 


structure  Of  TUNIS 


User  Control 
User 
Family 


Pile  System 
Tree  File 
Flat  Pile 
Cache 


Memory  Management 
Memory 


Device  Modules 
Device  Manager 
Teletype 
Disk 


Kernel  and  Utilites 
Kernel 
dock 
Panic 


Figure  1 

We  now  briefly  describe  the  twelve  modules  of  TUNIS. 

The  Kernel  is  the  lowest  layer  of  TUNIS  and  supports  Concurrent  Euclid 
processes  and  monitors.  The  kernel  time-slices  processes  and  controls  mutual 
exclusion  within  monitors.  The  kernel  hides  interrupts  from  the  upper  layers  of 
the  operating  system  and  provides  procedures  that  allow  Concurrent  Euclid 
processes  to  control  I/O  devices.  Additional  functions  exist  within  the  kernel  to 
support  TUNIS  machine  dependent  functions.  The  memory  management  registers 
are  set  by  the  kernel.  Execution  of  user  processes  is  supported  by  a  kernel  pro¬ 
cedure  that  transfers  control  to  a  user  process  and  returns  information  to  allow 
the  operating  system  to  determine  the  cause  of  return.  The  kernel  also  supports 
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a  dock  pseudo-device  that  interrupts  once  a  second.  The  kernel  must  be  rewrit¬ 
ten  for  each  new  architecture,  as  it  is  written  in  assembly  language.  This  is  due 
to  the  fact  that  the  Kernel  performs  many  functions  that  are  not  possible  or 
efficient  to  do  in  Concurrent  Euclid. 

The  dock  Manager  keeps  the  current  time  of  day  and  can  delay  a  TUNIS  pro¬ 
cess  for  a  specified  period.  The  Clock  Manager  accesses  the  kernel  pseudo-device 
clock  to  measure  time. 

The  Panic  Manager  prints  error  messages  for  TUNIS. 

The  Device  Manager  controls  the  1/0  for  TUNIS,  and  calls  the  appropriate 
Device  Handler.  This  module  is  used  by  the  File  System  to  map  all  I/O  devices  to 
a  uniform  format,  removing  device  dependencies  from  the  File  System.  Only  the 
Device  Manager  knowns  what  devices  are  on  the  system. 

The  Disk  Manager  controls  the  disks  for  TUNIS.  It  supports  disks  which  con¬ 
sist  of  linear  arrays  of  512  byte  blocks.  The  disk  scheduling  algorithms  are 
machine  independent,  and  call  a  device  dependent  module  to  perform  the  I/O. 

The  Teletype  Manager  controls  terminal  I/O  for  TUNIS.  It  is  machine 
independent  except  for  the  TtyDoIO  module  that  directly  controls  the  terminals. 
The  TtyDoIO  module  consists  of  less  than  one  page  of  Concurrent  Euclid  code. 

The  Memory  Manager  controls  the  allocation  of  physical  memory  to  user 
processes.  The  Memory  Manager  swaps  user  processes  to  a  known  area  of  the 
disk  when  there  is  more  memory  required  by  user  processes  than  is  available  on 
the  system,  and  performs  long  term  scheduling  of  user  processes  by  controlling 
the  swapping  of  user  processes.  User  processes  may  only  execute  when  they  are 
swapped  into  memory.  The  Memory  Manager  is  machine  independent  over  a  class 
of  machines  that  use  swapping  for  memory  control.  A  version  of  this  module 
using  paging  hardware  is  undc'r  design.  This  w^ill  allow  TUNIS  to  run  on  arehitcic- 
tures  with  paging  hardware. 
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The  Cache  Manager  is  the  lowest  module  in  the  File  System  layer  of  TUNIS. 
The  Cache  Manager  buffers  1/0  requests  to  attempt  to  minimize  disk  I/O  and 
allows  reads  and  writes  of  partial  disk  blocks. 

The  Flat  File  Manager  controls  allocation  and  deletion  of  files  on  disk,  and 
supports  random  access  to  files.  The  files  are  identified  by  integers. 

The  Tree  FUe  Manager  supports  the  directory  structure  of  TUNIS,  and  maps 
between  file  names  and  file  numbers.  This  module  updates  directories  and 
enforces  file  permission  rights.  The  Tree  File  Manager  also  supports  links 
between  files,  pipes,  and  the  interfaces  to  device  control  managers.  The  Cache, 
Flat  File,  and  Tree  File  Managers  are  machine  independent. 

The  Family  Manager  handles  creation  and  deletion  of  user  processes.  The 
Family  Manager  also  handles  communication  between  user  processes,  and  pro¬ 
vides  time-out  notification  to  user  programs.  This  module  is  machine  indepen¬ 
dent. 

The  User  Manager  is  a  collection  of  envelope  processes.  Each  envelope  pro¬ 
cess  is  the  interface  between  a  user  program  and  TUNIS  (see  figure  2).  The 
Envelope  swrrounds  the  user  program  and  translates  the  user  system  calls  into 
procedure  calls  to  the  lower  layers  of  TUNIS.  The  envelope  and  the  user  process 
run  as  coroutines,  the  envelope  becoming  the  user  through  a  kernel  procedure, 
and  the  user  returning  to  the  envelope  when  a  user  fault  occurs.  The  envelope 
then  fetches  the  call  arguments  and  calls  the  appropriate  routines.  The  envelope 
then  returns  the  results  to  the  user  program  and  resumes  executing  the  user  pro¬ 
cess,  returning  from  the  system  call.  The  User  manager  contains  machine 
dependent  routines  to  initialize  the  user  process,  and  to  access  the  parameters  of 
system  calls. 
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User-Envelope  Interface 


User  Process 


(system  calls) 


Envelope 


(procedure  calls) 


Figure  2 


TUNIS  consists  of  five  machine  independent  modules  (File  System,  Family 
Manager,  and  Panic  Manager),  three  almost  machine  independent  modules  (User 
Manager,  Teletype  Manager,  Clock  Manager),  two  device  dependent  modules  (Disk 
Manager,  Device  Manager),  the  Memory  Manager,  which  is  mostly  machine 
independent  over  a  class  of  machines,  and  the  kernel,  which  is  completely 
machine  dependent.  The  machine  independent  portions  of  TUNIS  comprise 
approximately  90%  of  the  source  code  of  TUNIS. 
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CHAPTER  3 


Other  Portable  Operating  Systems 

We  have  seen  some  general  techniques  for  developing  portable  operating 
systems,  and  a  quick  overview  of  the  structure  of  TUNIS.  This  chapter  will  briefly 
examine  three  operating  systems  for  small  systems  that  have  been  transported 
in  the  past.  All  were  written  in  low  level,  weakly  typed  languages  that  do  not  sup¬ 
port  concurrency. 

3.1.  UNIX 

UNIX*  [Thompson,  Ritchie]  has  become  a  standard  for  operating  systems  for 
small  to  medium  sized  computer  system.  It  is  a  small  and  simple  operating  sys¬ 
tem,  and  is  running  on  many  installations  worldwide.  UNIX  was  first  developed  for 
the  Digital  PDP-7  and  PDP-9  computers,  and  then  moved  to  the  PDP-11  family. 
Originally  UNIX  was  written  in  assembly  language,  but  it  was  rewritten  in  C,  an 
unstructured,  weakly  typed  language.  UNIX  has  been  transported  to  various 
machines,  including  the  Interdata  832,  the  IBM  370,  and  the  VAX  11  family.  More 
recently,  UNIX  has  been  moved  to  the  Motorola  68000  and  the  National  Semicon¬ 
ductor  16032  microcomputers.  For  the  VAX,  paging  was  added  at  the  cost  of  dou¬ 
bling  the  amount  of  the  source  code.  UNIX  has  a  hierarchical  file  system,  and 
treats  I/O  devices  with  the  same  interface  used  for  disk  files.  A  file  is  considered 
by  the  operating  system  to  be  a  linear  sequence  of  bytes  without  any  enforced 
structure. 

UNIX  has  a  simple  command  language  interface  (the  shell)  that  is  not  part  of 
the  operating  system,  but  runs  as  a  user  program.  The  shell  is  both  a  command 
language  and  a  programming  language.  The  shell  language  provides  control  flow 
constructs  and  variables,  and  serves  as  a  user  interface  to  the  facilities  of  the 

♦UNIX  is  a  Trademark  of  Bell  Laboratories. 
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UNIX  operating  system. 

The  implementation  of  UNIX  differs  from  that  of  TUNIS  in  several  ways.  In 
UNIX,  only  one  process  can  be  active  within  the  nucleus  at  one  time  and  control  is 
explicitly  passed  from  one  process  to  another.  Mutual  exclusion  of  data  between 
processes  and  interrupt  routines  is  accomplished  by  disabling  interrupts  during 
the  critical  sections. 

3.2.  TROTH 

THOTH  [Cheriton]  is  a  UNIX-like  operating  system  developed  at  the  Univer¬ 
sity  of  Waterloo.  THOTH  is  designed  to  be  a  real-time  operating  system.  A  real¬ 
time  operating  system  guarantees  that  no  more  than  a  given  maximum  time  will 
elapse  before  the  system  can  respond  to  an  external  stimulus.  THOTH  was  first 
implemented  in  May  1976  on  a  Data  General  Nova  computer,  in  the  language  Eh, 
an  untyped,  unstructured  language  descended  from  BCPL.  In  August  1976,  THOTH 
was  transported  to  a  Texas  Instruments  990  computer.  Since  then,  THOTH  has 
been  re-written  in  ZED,  a  weakly  typed  language  also  descended  from  BCPL,  and 
has  been  transported  to  three  more  computer  architectures. 

THOTH  is  implemented  as  a  message  passing  system.  Message  passing  is 
used  to  transfer  information  between  concurrent  processes  in  the  operating  sys¬ 
tem.  THOTH  can  be  generated  in  many  versions,  from  a  stand-alone  simple  pro¬ 
gram  to  a  system  supporting  multiple  terminals  and  users. 

THOTH  is  designed  to  be  implementable  on  a  subset  of  machines  with  the  fol¬ 
lowing  features: 

-  a  word  must  be  at  least  16  bits  long. 

-  pointers  to  a  word  must  fit  in  a  word. 

-  inlt'rrupts  can  be  disabled. 

-  a  word  may  be  indivisibly  modified. 
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The  THOTH  implementation  differs  from  TUNIS  in  using  message  passing  for 
processes  synchronization  instead  of  monitors.  The  message  passing  primitives 
are  not  part  of  the  implementation  Lajnguage,  but  are  procedure  calls  imple¬ 
mented  using  a  low  level  kernel.  ! 

3.3.  CP/MandMP/M 

CP/M  (Control  Program  for  Microcomputers)  [Kildall]  is  becoming  a  stan¬ 
dard  for  microcomputer  operating  systems.  CP/M  is  a  single  user,  single  process 
operating  system  developed  for  small  systems  with  one  or  two  floppy  disk  drives. 
CP/M  was  originally  developed  for  the  Intel  8080  computer.  CP/M  was  written  in 
PL/M,  a  PL/l  dialect  for  microcomputers,  in  1974.  Since  that  time,  CP/M  has 
been  used  by  almost  200,000  installations  around  the  world.  CP/M  has  a  single 
user  file  system  designed  to  prevent  data  loss  and  use  recoverable  directory 
information  to  enable  floppy  disks  to  be  changed  at  will  without  losing  data  or 
files.  CP/M  was  redesigned  in  1979  to  have  a  table  driven  I/O  interface  to  ease 
adaptation  to  different  system  configurations.  CP/M  has  been  transported  to  the 
Zilog  Z80  and  the  Intel  8086  microcomputers. 

MP/M  (Multiprogramming  Monitor  for  Micro  Computers)  is  an  enhanced  ver¬ 
sion  of  CP/M  designed  to  support  multiple  terminals  and  multiprogramming. 
Process  communication  in  MP/M  is  performed  through  Queues,  which  are  similar 
to  buffered  message  passing  communication. 

CP/M  is  not  a  good  example  of  a  machine  independent  operating  system 
because  both  the  Z80  and  8086  are  supersets  of  the  8080  architecture.  CP/M  is 
portable  across  a  wide  class  of  I/O  devices,  as  it  is  easily  reconfigured  to  support 
new  devices  and  configurations. 

3.4.  Comparisons 

The  three  operating  systems  examined  have  all  been  transported  to  different 
machines.  THOTH  is  the  only  operating  system  that  was  designed  to  be  easily 
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transported  across  different  architectures.  This  is  shown  by  the  number  of 
machines  it  was  supporting  in  a  short  period  of  time.  THOTH  shares  with  TUNIS 
the  use  of  processes  and  synchronization  primitives  within  the  operating  system, 
although  for  THOTH,  these  are  not  directly  supported  by  the  implementation 
language. 

The  next  four  chapters  will  discuss  the  four  major  layers  of  TUNIS,  and 
examine  the  methods  used  by  TUNIS  to  maximize  portability. 


-16- 


CHAPTER  4 


Managing  the  Hardware 

Managing  the  hardware  of  different  computer  systems  will  always  be  very 
machine  dependent.  This  chapter  explains  how  concurrent  activities  in  an 
operating  system  are  controlled  and  how  data  sharing  between  processes  is 
accomplished.  Also  discussed  is  responding  to  I/O  interrupts  and  the  passing  of 
device  completion  data  to  upper  layers  of  the  system. 

4.1.  Managing  the  Processor 

There  are  many  concurrent  activities  in  an  operating  system.  These  can 
arise  from  user  processes  as  well  as  the  processes  internal  to  the  operating  sys¬ 
tem  that  control  and  manage  resources.  The  operating  system  must  share  the 
processor  resources  between  these  concurrent  activities.  This  can  be  done  with 
co-routines  explicitly  giving  up  control,  as  is  done  in  UNIX.  In  THOTH,  a  process 
sending  a  message  gives  up  control  of  the  processor  until  it  receives  a  reply  to 
the  message.  In  TUNIS,  the  processor  time  is  shared  by  the  kernel  level,  and  each 
process  appears  to  have  its  own  processor.  A  TUNIS  process  has  no  knowledge 
about  the  scheduling  of  the  processor.  This  has  the  advantage  that  multi¬ 
processing  could  be  added  to  TUNIS  with  only  a  change  to  the  kernel,  because 
processes  do  not  depend  on  a  single  processor  model.  Explicit  process  scheduling 
assumes  that  the  currently  running  process  is  the  only  process  active  in  the 
operating  system,  allowing  that  process  exclusive  access  to  shared  variables. 
This  assumption  may  be  invalid  on  a  multiprocessor  system. 

4.1.1.  Scheduling 

The  TUNIS  kernel  performs  short  term  scheduling  of  processes  below  the 
level  of  the  operating  system.  Concurrent  Euclid  specifies  that  the  scheduling  of 
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processes  must  be  fair.  However,  within  the  operating  system,  a  process  can 
explicitly  request  that  the  kernel  give  it  a  high  dispatching  priority.  This  is  used 
to  allow  processes  managing  1/0  devices  to  respond  quickly  to  device  interrupts. 
Higher  priorities  in  TUNIS  are  also  used  to  allow  the  internal  processes  in  TUNIS 
to  execute  more  rapidly  than  user  processes.  These  system  processes  are  run  at 
regular  intervals,  and  the  higher  priority  prevents  the  processes  from  missing 
any  intervals. 

In  TUNIS,  a  process  may  give  up  control  of  the  processor  by  performing  a 
-wait  on  a  condition.  The  waiting  process  will  not  be  granted  the  processor  until 
the  process  is  removed  from  that  condition  through  a  signal.  In  general,  there  is 
a  boolean  expression  associated  with  each  condition  such  that  the  process  will 
wait  on  that  condition  if  the  expression  is  false,  and  when  the  expression  is  true, 
the  process  will  return  from  the  wait.  Another  method  of  processor  control  is  the 
UNIX  sleep  call,  where  all  processes  sleeping  on  an  event  will  wake  up  when  that 
event  occurs,  and  all  processes  must  test  to  see  if  they  can  acquire  the  resource, 
or  if  another  process  has  acquired  the  resource  first.  The  processes  that  have 
failed  to  acquire  the  resource  must  return  to  sleep. 

4.1.2.  Data  Sharing  Between  Processes 

An  important  part  of  an  operating  system  is  the  control  of  shared  data  struc¬ 
tures.  An  operating  system  must  ensure  that  its  data  structures  are  protected 
while  they  are  being  updated,  to  prevent  concurrent  writing  of  data  structures,  or 
the  reading  of  a  data  structure  during  an  update.  This  is  an  example  of  the 
readers-writers  problem  involving  concurrent  access  to  a  data  structure.  In 
UNIX,  this  is  done  by  explicitly  disabling  interrupts  during  critical  sections,  so 
that  no  other  activities  can  occur  while  the  update  is  done. 

TUNIS  uses  monitors  in  Concurrent  Euclid  to  ensure  that  simultaneous 
updates  of  shared  data  do  not  occur.  In  TUNIS,  monitors  controlling  access  to 
data  structures  are  used  in  two  fashions.  When  only  small  quantities  of  data  are 


-18- 


read  or  written  (usually  up  to  10  bytes  of  data),  a  process  enters  the  monitor, 
accesses  the  data  and  returns.  If  the  data  structure  is  large,  the  data  is  placed  in 
a  module,  and  an  internal  monitor  is  used  to  control  access  to  the  data.  A  process 
will  enter  this  monitor,  and  set  a  boolean  variable  to  mark  the  data  structure  "in 
zLse",  and  then  exit  the  monitor.  The  process  will  access  the  data  structure,  and 
then  reenter  the  monitor  to  unlock  the  data.  This  method  of  access  to  data  struc¬ 
tures  is  not  enforced  by  Concurrent  Euclid,  but  is  a  method  used  to  allow  access 
to  part  of  a  data  structure  without  blocking  access  to  the  rest  of  the  data  struc¬ 
ture.  All  processes  attempting  to  access  a  data  structure  using  this  method  must 
test  to  see  if  the  structure  is  locked,  and  wait  for  it  to  be  unlocked  if  necessary. 

The  first  method  of  data  sharing  is  superior  to  the  software  locking  method, 
because  simultaneous  access  to  data  structures  is  prevented  by  the  monitor.  The 
latter  method  is  more  vulnerable  to  programming  errors  than  placing  the  data 
within  the  monitor.  The  software  locking  method  is  more  efficient  when  different 
processes  want  access  to  separate  portions  of  a  data  structure.  A  monitor  will 
only  allow  one  process  at  a  time  to  access  the  data,  thus  serializing  a  parallel 
activity. 

4.2.  I/O  Interrupts 

An  operating  system  must  be  able  to  communicate  with  many  different  I/O 
devices.  For  typical  hardware,  these  devices  will  be  interrupting  the  processor 
whenever  status  information  is  ready.  A  portable  operating  system  should  have  a 
uniform  method  of  handling  I/O  devices  and  interrupts,  a  method  that  should  be 
flexible  enough  to  handle  all  devices  easily. 

There  are  two  methods  that  an  operating  system  can  use  to  respond  to  an 
interrupt  from  a  device.  The  kernel  may  invoke  a  subroutine  to  handle  the  inter¬ 
rupt,  and  that  subroutine  will  give  up  processor  control  explicitly.  This  is  the 
method  used  in  UNIX.  The  interrupt  routine  will  execute  with  interrupts  disabled, 
and  update  data  structures  as  needed,  and  then  start  another  I/O  operation 
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before  exiting. 


In  TUNIS,  interrupts  are  handled  using  another  method.  Device  interrupts 
are  treated  as  synchronous  events  by  the  device  controller  processes.  A  device 
controller  will  start  an  I/O  operation,  and  then  wait  for  the  interrupt  to  occur. 
The  upper  layers  of  the  system  do  not  see  the  interrupts,  as  the  kernel  intercepts 
them.  The  only  information  that  is  passed  up  to  the  device  controlling  process  is 
that  the  desired  interrupt  has  occurred.  A  set  of  kernel  routines  is  provided  to 
handle  interrupts.  A  proeess  wishing  to  communicate  with  a  device  will  call  the 
routine  Beginlo  to  disable  interrupts  and  allow  communication  with  the  device 
without  distractions.  After  giving  the  device  commands,  the  process  calls  the 
kernel  routine  Waitio,  passing  in  a  device  identification.  This  routine  has  the 
same  general  semantics  as  a  wait  in  a  monitor;  the  process  is  not  run  until  it  is 
signalled  by  the  kernel.  The  kernel  signals  the  waiting  process  when  the  interrupt 
corresponding  to  the  device  identification  is  received.  The  waiting  process  is 
then  dispatched  with  interrupts  disabled.  After  servicing  the  device,  the  process 
will  then  call  the  routine  BJndIo  to  re-enable  interrupts.  Beginlo  and  Bndio 
correspond  to  the  EnterMonitor  and  ExitMonitor  of  a  monitor  associated  with  that 
device. 

This  method  causes  interrupts  to  appear  synchronous  to  the  process  con¬ 
trolling  the  device;  there  is  no  means  provided  to  do  asynchronous  I/O.  This 
implies  that  all  active  devices  (devices  that  cause  unexpected  interrupts)  must 
have  a  process  dedicated  to  that  device  that  will  be  waiting  for  the  next  interrupt 
to  occur.  Passive  devices,  such  as  a  disk  drive,  will  be  serviced  by  the  calling  pro¬ 
cess,  which  will  wait  for  the  I/O  to  complete  before  continuing.  Buffering  I/O  by 
read-ahead  and  write-behind  of  user  I/O  requests  is  performed  by  processes  that 
accept  an  I/O  request  and  perform  the  I/O  on  behalf  of  the  requesting  process. 
This  is  the  method  of  performing  asynchronous  I/O  requests  using  the  synchro¬ 
nous  Waitio  mechanism  and  an  extra  process. 
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This  synchronous  method  of  device  control  is  simple  and  leads  to  easily 
understood  device  controller  modules.  There  are  no  hidden  interactions  between 
the  device  control  procedures:  there  are  no  interrupt  servicing  routines  that  can 
be  hard  to  understand  and  difficult  to  debug.  The  advantage  of  the  asynchronous 
device  routines  is  that  there  is  little  overhead.  For  synchronous  device  inter¬ 
rupts,  the  overhead  of  process  dispatching  may  limit  the  maximum  throughput  of 
the  device. 

The  use  of  a  language  that  supports  concurrency,  together  with  a  small  ker¬ 
nel  implementing  the  language,  leads  to  implementations  that  are  simpler  and 
easier  to  understand  than  those  written  in  languages  using  explicit  process 
switching.  The  designer  of  an  operating  system  should  not  have  to  concern  him¬ 
self  with  details  of  process  switching  and  interrupt  disabling,  but  should  allow  the 
implementation  language  to  provide  these  implicitly. 

Synchronous  interrupts  are  another  useful  tool  that  can  be  used  to  simplify 
the  design  and  implementation  of  an  operating  system  by  simplifying  the  device 
controller  modules. 
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CHAPTER  5 


Portability  of  the  Lower  Layers:  Memory  Management  and  I/O 


This  chapter  discusses  memory  management  in  an  operating  system  and  use 
of  memory  protection  hardware.  The  structure  of  I/O  driver  modules  is  also  dis¬ 
cussed,  showing  the  encapsulation  of  machine  dependencies  with  the  device  con¬ 
troller  modules. 

5.1.  Memory  Management 

The  Memory  Module  in  an  operating  system  controls  the  allocation  of 
memory  to  user  processes  and  performs  read  and  writes  to  user  process  memory. 
Allocation  of  memory  to  user  processes  implies  that  a  method  must  be  used  to 
allocate  physical  memory  when  the  combined  sizes  of  all  user  process  memory  is 
larger  than  available  physical  memory.  Two  common  methods  of  accomplishing 
this  are  swapping  and  paging . 

5.1.1.  Swapping  and  Paging  Algorithms 

Swapping  of  user  processes  is  performed  by  writing  the  user  process  to  some 
auxiliary  storage  (usually  a  disk  drive),  and  then  reading  another  user  process 
into  the  vacated  memory.  Because  user  processes  are  of  different  sizes,  it  is 
necessary  to  use  a  storage  allocation  scheme  to  keep  track  of  all  the  available 
spaces  in  memory  and  on  the  auxiliary  store.  Swapping  can  be  used  on  a  com¬ 
puter  with  no  memory  management  hardware,  and  is  generally  used  on  systems 
with  Base-Limit  type  memory  management  hardware.  Base- Limit  hardware  relo¬ 
cates  user  processes  anywhere  in  physical  memory,  while  preventing  the  user 
from  accessing  memory  outside  his  virtual  memory.  The  Base  is  a  register  that  is 
added  to  user  virtual  memory  address  to  locate  tlic  physical  memory  address  to 
be  referenced,  and  the  Limit  is  a  register  that  controls  the  maximum  virtual 
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address  that  can  be  accessed  by  the  user  process.  Computer  systems  without 
memory  management  hardware  may  still  use  swapping  to  run  multiple  user 
processes,  but  these  processes  must  always  be  loaded  at  their  initial  load 
address,  and  the  operating  system  cannot  take  maximum  advantage  of  the  avail¬ 
able  physical  memory.  The  lack  of  memory  management  hardware  also  means 
that  the  operating  system  is  not  protected  from  user  processes.  A  reliable 
operating  system  must  include  some  form  of  protection  from  user  processes, 
either  through  memory  hardware  or  secure  software  support  (compilers  and  link¬ 
ers). 

Paging  of  user  processes  requires  extensive  memory  management  hardware. 
The  user  virtual  memory  is  divided  into  fixed  size  pages,  and  physical  memory  is 
partitioned  similarly.  The  paging  hardware  maps  user  addresses  to  physical 
addresses  through  a  page  table.  The  hardware  uses  the  page  table  to  determine 
the  physical  memory  page  containing  the  user  virtual  page.  There  is  additional 
access  information  associated  with  each  entry  in  the  page  table  to  determine  how 
a  user  can  access  a  given  page,  and  determine  if  the  page  is  in  physical  memory. 
If  the  page  is  not  in  memory,  the  memory  module  will  bring  it  into  memory,  and 
let  the  user  process  continue  executing. 

Paging  algorithms  simplify  the  problem  of  allocating  memory  to  user 
processes,  as  any  page  will  fit  into  a  page  in  memory.  The  new  problem  is  deter¬ 
mining  the  proper  page  to  remove  from  physical  memory  when  all  physical 
memory  is  allocated.  The  optimal  algorithm  is  to  remove  the  page  that  will  be 
referenced  the  longest  time  from  the  present;  this  algorithm  is  understandably 
hard  to  implement.  There  are  many  satisfactory  page  replacement  algorithms, 
including  the  Least  Recently  Used  (LRU)  algorithm,  which  chooses  the  page  that 
has  not  been  referenced  in  the  longest  time,  in  the  theory  that  this  page  will  not 
be  referenced  for  a  long  time  in  the  future. 
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5,1.2.  Direct  I/O  to  User  Memory 


Ideally,  the  Memory  Module  is  the  only  module  in  the  operating  system  that 
knows  anything  about  the  location  of  user  processes  in  physical  memory,  the  size 
of  the  user  process,  and  long  term  scheduling  information.  This  works  because  all 
references  to  the  user  process  by  the  operating  system  pass  through  the  Memory 
Module.  Unfortunately,  this  assumption  is  not  true  when  performing  1/0  directly 
into  the  user’s  virtual  memory.  A  method  of  avoiding  this  problem  is  to  forbid  1/0 
to  be  performed  to  or  from  the  user’s  memory  directly,  but  instead  force  the  1/0 
to  be  done  to  system  space,  and  then  moved  to  the  user.  In  general,  this  is  not  a 
practical  restriction  because  it  involves  an  extra  transfer  of  data. 

To  perform  I/O  directly  to  user  memory,  the  upper  levels  of  the  operating 
system  must  alert  the  Memory  Module,  and  the  Memory  Module  must  provide 
enough  information  to  be  passed  to  a  device  controller  module  to  allow  the  I/O  to 
be  performed  to  the  user’s  memory.  There  are  two  possible  methods  for  accom¬ 
plishing  this: 

(1)  The  Memory  Module  may  ensure  that  the  affected  pages  are  contiguous  in 
memory  and  locked  in  place  and  return  a  pointer  to  the  start  of  the  area. 

(2)  The  Memory  Module  must  lock  the  desired  pages  into  memory,  and  return  a 
map  of  the  locations  of  the  pages. 

Either  method  allows  the  device  module  to  access  the  desired  pages,  but  the 
first  method  would  be  inconvenient  to  accomplish  in  a  paging  system  without 
complicated  storage  allocation  algorithms.  For  devices  similar  to  tape  drives 
with  large  blocking  factors,  it  is  highly  desirable  for  the  hardware  to  have  a  relo¬ 
cation  map  similar  to  the  fjaging  hardware.  The  Memory  Module  must  mark  the 
affected  pages  as  modified  if  information  was  written  into  the  pages. 

The  current  version  of  the  TUNIS  Memory  Manager  uses  the  first  method, 
because  the  swapping  algorithms  already  keep  ail  of  the  user  process  in  contigu¬ 
ous  memory.  The  paging  version  of  the  Memory  Manager  uses  the  second  method 
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of  transfering  data. 

In  TUNIS,  the  Memory  Module  is  also  responsible  for  the  creation  and  dele¬ 
tion  of  partitions  for  user  processes,  changing  the  size  of  a  user  partition,  and 
long-term  scheduling  of  user  processes.  The  scheduling  is  done  in  a  swapping 
system  by  selecting  the  user  to  be  swapped  in  or  out,  while  in  a  paging  system, 
scheduling  is  done  with  a  page  replacement  algorithm  and  possibly  a  requirement 
that  a  minimum  percentage  of  a  user’s  pages  must  be  in  memory  before  the  user 
process  can  be  run. 

5.1.3,  Memory  Management  in  TUNIS 

In  TUNIS,  the  Memory  Module  is  designed  for  a  swapping  system  on  the  PDF 
11/23  and  MC68000,  and  a  paging  version  for  the  VAX  11/780  is  currently  being 
designed.  The  Memory  Module  is  also  responsible  for  ensuring  that  the  user  is  in 
memory  before  user  execution.  TUNIS  associates  a.  virtual  memory  number  with 
each  user  process,  and  an  address  in  user  space  is  encoded  as  a  virtual  memory 
number  and  an  address  within  that  memory.  There  are  separate  virtual 
memories  for  the  system  virtual  memory  and  for  the  physical  memory. 

TUNIS  must  ensure  that  the  user  process  is  in  memory  before  executing  the 
user  process.  The  Memory  Manager  contains  an  entry  point  that  will  lock  the  user 
process  into  memory,  calls  the  Kernel  to  execute  the  user  process,  and  then 
unlocks  the  user  process.  This  prevents  the  user  process  from  begin  locked  into 
memory  when  it  is  not  executing,  allowing  other  user  processes  to  acquire  the 
memory  while  the  operating  system  is  performing  a  system  call  on  behalf  of  the 
user  process. 

In  principle,  TUNIS  can  be  easily  transported  to  a  new  architecture  with 
memory  mapping  hardware  to  support  either  swapping  or  paging.  In  practice, 
details  of  the  mapping  hardware  may  require  modifying  the  Memory  Module. 
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Memory  Management  in  an  operating  system  will  be  dependent  on  the 
hardware  of  the  machine.  The  basic  dependency  is  the  nature  of  the  memory 
management  hardware:  swapping  or  paging  systems.  The  algorithms  for  user  pro¬ 
cess  control  will  be  machine  independent,  but  allocation  of  memory  and  access  to 
user  memory  will  depend  on  the  nature  of  the  memory  mapping  hardware.  For 
TUNIS,  the  current  Memory  Manager  could  handle  swapping  systems  with  a 
minimum  of  change,  but  a  paging  Memory  Manager  would  involve  rewriting  the 
Memory  module. 

5.2.  I/O  Modules 

Device  Modules  are  inherently  machine  dependent  routines.  The  algorithms 
for  scheduling  a  device  and  splitting  I/O  requests  to  manageable  sizes  are 
machine  independent,  but  the  mechanics  of  communicating  with  the  hardware 
are  dependent  on  both  the  device  and  the  computer  to  which  it  is  attached. 

Portability  can  be  aided  by  requiring  all  device  modules  to  have  a  common 
interface  to  the  upper  levels  of  the  system,  and  by  placing  all  device  dependent 
code  within  small  device  dependent  modules.  This  gathering  of  device  dependent 
functions  within  a  module  aids  in  modifying  the  device  drivers  in  TUNIS  by 
separating  the  device  independent  code  from  that  which  must  be  rewritten  for  a 
new^  device  interface.  The  common  interface  enables  device  modules  to  be  easily 
transported  across  similar  machines.  In  TUNIS,  all  I/O  requests  pass  through  the 
Device  Manager  with  a  uniform  interface  to  all  devices  on  the  system.  Each  I/O 
request  is  identified  by  a  device  number,  and  the  Device  Manager  routes  the 
request  to  the  proper  device. 

Each  module  accepts  an  loRequestParameter  and  performs  the  I/O,  hiding 
device  specific  details  such  as  blocking  factors  and  splitting  1/0  across  device 
bouxiJancs  fruiii  the  upper  layers  of  the  uperaLiug  s>sLeiu.  AIL  devices  are  syn- 
..  1 11  .,/i  loiui  Lu  i.ufe  calling  process,  therefore  active  devices  such  as  teletype  input 
must  have  a  dedicated  process  that  is  always  waiting  for  the  next  interrupt  to 
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occur.  This  process  will  service  the  interrupt,  and  then  wait  for  the  next  inter¬ 
rupt. 

The  general  form  of  an  1/0  module  in  TUNIS  is: 

I/O  MODULE 


Do  10  Module 

Device  Dependent 
Routines 


Monitor 

Shared  Data  Structures 
and  Routines 

Device  Independent  Routines 
Entry  Points  to  Module 
Internal  Processes 


Figure  3 

The  device  dependent  routines  in  an  I/O  module  are  collected  into  a  DoIO 
module  within  the  device  controller.  The  routines  within  the  DoIO  module  are 
responsible  for  communicating  with  the  device,  and  they  present  a  device 
independent  interface  to  the  rest  of  the  I/O  module.  This  allows  a  new  device  to 
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be  easily  supported  by  changing  the  DoIO  module  of  a  device  controller  module. 
The  I/O  module,  with  the  exception  of  any  DoIO  modules,  will  be  completely 
machine  independent. 

An  active  device  will  have  internal  processes  to  respond  to  interrupts,  while 
a  passive  device  (disks)  will  have  the  calling  process  perform  the  I/O  and  wait  for 
the  interrupt.  Passive  I/O  modules  will  not  have  internal  processes. 

User  processes  in  TUNIS  may  be  signalled  by  other  user  processes.  TUNIS 
ensured  that  the  signal  is  noticed  rapidly  by  having  the  Envelope  check  for  the 
presence  of  a  signal  every  2  to  3  seconds.  To  implement  this  check,  I/O  modules 
that  can  have  indefinite  waits  on  I/O  requests  (such  as  the  Tty  module)  will  return 
a  Time  Out  status  after  several  seconds  of  waiting,  and  the  upper  levels  of  the  sys¬ 
tem  will  reissue  the  I/O  request  after  checking  for  signals.  The  Tty  module  uses 
a  timing-out  process  to  abort  1/0  requests  that  are  not  satisfied  within  this  time. 

1/0  device  controllers  are  device  dependent,  but  isolation  of  routines  within 
DoIO  modules  eases  the  switch  to  support  a  new  device.  For  example,  the  TUNIS 
Teletype  Manager  is  over  95%  machine  independent,  and  can  easily  support 
different  terminals. 
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CHAPTER  6 


Portability  of  the  Middle  Layers:  The  File  System 


Parts  of  the  lower  layers  of  the  operating  system  have  been  shown  to  be 
machine  and  device  dependent.  This  chapter  examines  the  file  system  of  TUNIS, 
demonstrating  that  it  can  be  machine  independent.  The  TUNIS  file  system  con¬ 
sists  of  three  modules:  the  Cache  module,  the  Flat  File  module,  and  the  Tree  File 
module. 

6.1.  The  Cache  Module 

The  Cache  module  in  TUNIS  performs  the  buffering  for  the  file  system.  A  pool 
of  buffers  within  the  Cache  module  is  used  to  decrease  the  amount  of  disk  I/O 
performed  by  the  file  system  by  keeping  copies  of  recently  referenced  disk 
blocks  in  memory.  Minimizing  I/O  increases  overall  system  performance  by 
avoiding  waits  for  disk  accesses  and  because  I/O  transfers  cause  memory  refer¬ 
ences,  slowing  the  processor  during  the  transfer. 

The  Cache  module  attempts  to  keep  frequently  accessed  blocks  in  memory 
by  writing  out  modified  blocks  only  when  a  buffer  is  needed  to  hold  a  new  disk 
block.  At  the  same  time,  the  Cache  attempts  to  satisfy  I/O  requests  as  quickly  as 
possible,  which  implies  that  buffers  should  always  be  available  to  be  filled.  In 
TUNIS,  this  conflict  is  settled  by  an  Ager  process  that  occasionally  writes  buffers 
to  disk.  If  a  buffer  has  not  been  referenced  during  two  visits  by  the  Ager.  the 
block  is  written  to  disk  and  marked  as  available.  This  prevents  the  disk  copies  of 
blocks  from  becoming  out  of  date,  frees  up  a  buffer,  and  keeps  the  old  contents  of 
the  buffer  untouched,  so  future  references  to  that  block  might  avoid  a  disk  read. 
The  effect  of  the  Ager  on  system  performance  will  not  be  known  until  detailed 
measurement  is  possible. 
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The  Cache  module  in  TUNIS  has  another  function;  it  supports  reads  and 
writes  of  partial  disk  blocks.  The  Disk  module  only  supports  reads  and  writes  of 
whole  disk  blocks.  The  partial  block  reads  and  writes  are  used  by  the  file  system 
to  access  disk  files. 

The  Cache  module  is  machine  independent,  because  all  I/O  is  performed 
through  the  Device  Manager. 

6.2.  The  Flat  File  System 

The  UNIX  file  system  is  organized  as  a  tree  structure,  with  directories  as  the 
inner  nodes  of  the  tree,  and  regular  and  I/O  device  files  as  the  leaves  of  the  tree. 
The  Flat  File  module  treats  all  files  on  a  disk  identically,  and  leaves  the  tree 
structure  of  the  file  system  to  be  implemented  by  the  Tree  File  module  with  the 
tools  provided  by  the  Flat  File  module.  The  Flat  File  module  supports  the  crea¬ 
tion,  deletion,  and  dynamic  expansion  of  disk  files.  The  Flat  File  module  allows 
random  access  to  any  byte  within  a  file. 

The  Flat  File  module  is  responsible  for  the  allocation  of  free  disk  blocks  to 
files  as  files  are  expanded,  and  the  recovery  of  these  blocks  upon  file  deletion. 
The  Flat  File  module  provides  entries  to  open  and  close  disk  files,  and  to  read  and 
write  files.  Other  entries  return  information  about  file  status,  and  maintain  file 
information  necessary  for  the  implementation  of  a  directory  tree  structure.  This 
information  includes  the  access  permission  rights  of  a  file,  the  owner  of  the  file, 
and  a  link  count,  which  records  the  number  of  directory  entries  that  reference  a 
given  file.  When  the  link  count  drops  to  zero,  the  file  is  unreferenced  and  is 
deleted. 

Within  the  Flat  File  module,  files  are  named  by  integers,  called  i-numbers. 
The  Tree  File  module  maps  user  names  to  disk  file  numbers  to  access  a  file. 

The  Flat  File  module  is  machine  independent  for  two  reasons.  First,  all  1/0  is 
performed  through  the  Cache  module,  so  the  module  is  device  independent,  and 
second,  it  is  unnecessary  to  specify  file  size  or  organization.  File  size  is 
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dynamically  expandable  as  long  as  space  remains  on  the  disk,  and  need  not  be 
specified  in  device  dependent  forms,  such  as  tracks  or  cylinders,  and  TUNIS 
places  no  structure  on  a  disk  file,  considering  a  file  to  be  an  array  of  bytes.  Any 
structure  within  a  file  is  determined  solely  by  the  programs  that  access  the  file, 
not  the  operating  system.  Random  access  to  the  entire  file  allows  any  desired 
structure  to  be  imposed  on  the  file  by  an  application  program.  The  lack  of  struc¬ 
ture  imposed  by  the  operating  system  has  the  advantage  of  simplifying  the  file 
system  by  eliminating  the  need  for  multiple  access  methods. 

6.3.  The  Tree  File  Module 

The  Tree  File  module  uses  the  facilities  provided  by  the  Flat  File  module  to 
implement  the  directory  tree  structure.  Directories  are  files  that  map  file  names 
to  i-numbers.  Only  the  operating  system  may  update  a  directory,  but  read  access 
is  permitted  to  user  programs.  Directory  entries  may  point  to  ordinary  files  or  to 
other  directories,  and  a  file  is  named  by  its  path  from  the  root  of  the  directory 
tree  or  from  the  current  directory.  A  naming  convention  allow  movement  up  the 
layers  of  the  tree. 

The  file  system  provides  links  between  files,  allowing  different  path  names  to 
refer  to  the  same  file.  Links  may  be  made  to  ordinary  files,  but  not  to  directories. 
This  ensures  that  no  cycles  are  introduced  into  the  directory  tree.  The  Tree  File 
module  also  provides  pipes,  unnamed  files  that  act  as  FIFO  queues.  These  are 
used  to  allow  the  output  from  one  program  to  be  directed  to  the  input  of  another 
program.  A  pipe  is  created  by  a  system  call,  and  may  be  accessed  by  the  descen- 
dents  of  the  process  that  created  the  pipe. 

The  Tree  File  module  translates  between  special  (I/O  device)  files  and  the 
corresponding  device  modules.  TUNIS  treats  I/O  devices  as  though  they  were 
disk  files  and  the  Tree  File  module  translates  user  requests  to  I/O  requests  to  the 
Device  Manager,  which  then  passes  the  requests  to  the  proper  device  controller 
module. 
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The  Tree  File  module  is  machine  independent  because  all  disk  I/O  is  per¬ 
formed  through  the  Flat  File  module,  all  other  I/O  requests  pass  through  the  Dev¬ 
ice  Manager,  and  access  to  user  path  names  is  performed  through  the  Memory 
module.  All  of  the  internal  logic  is  machine  independent. 


In  summary,  all  modules  in  the  file  system  are  machine  independent  because 
they  perform  all  I/O  through  modules  of  lower  layer  of  the  operating  system. 
This  separation  of  functions  has  allowed  the  entire  file  system  layer  of  TUNIS, 
which  accounts  for  approximately  40%  of  the  source  code,  to  be  completely  port¬ 
able. 
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CHAPTER  7 


Communicating  with  the  User  Process 

The  previous  chapter  showed  that  the  File  System  in  an  operating  system  can  be 
completely  machine  independent.  The  User  Control  layer  of  an  operating  system, 
the  modules  that  support  the  execution  of  user  programs,  are  machine  dependent 
in  two  areas.  These  areas  are  information  transfer  between  the  user  process  and 
the  operating  system,  and  the  mechanics  of  dispatching  user  processes. 

7.1.  The  Operating  System  to  User  Interface 

User  programs  must  pass  arguments  to  system  calls  and  receive  the  results 
of  the  calls.  The  methods  used  to  pass  arguments  will  depend  on  the  architecture 
of  the  machine. 

The  operating  system  could  be  directly  called  in  the  same  manner  as  a  nor¬ 
mal  procedure  call,  but  there  are  several  reasons  why  this  is  not  practical. 
Different  high  level  languages  may  use  different  procedure  calling  sequences  and 
therefore  there  is  no  unique  calling  sequence  to  use.  Additionally,  a  call  to  the 
operating  system  usually  invokes  a  trap  because  the  operating  system  is  outside 
the  address  space  of  the  user  program,  and  this  is  different  from  a  normal  pro¬ 
cedure  call.  It  seems  that  assembly  language  stubs  are  the  easiest  method  of 
allowing  machine  independent  high  level  language  interfaces  to  the  operating 
system. 
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A  related  problem  is  how  the  arguments  should  be  passed  from  the  stubs  to 
the  operating  system  on  a  given  machine.  Arguments  are  commonly  passed  to 
the  operating  system  in  one  of  4  ways: 


-  in  registers 

-  on  the  stack 

-  in  fixed  memory  locations 

-  in  memory  following  the  trap  instruction 

To  simplify  the  interface,  it  is  desirable  to  have  all  arguments  passed  using 
the  same  method.  Some  arguments  will  be  strings  of  unknown  length,  so  usually 
the  address  of  the  argument  is  passed  instead  of  the  argument  itself. 


Unless  compatibility  with  another  operating  system  is  necessary,  the 
designer  of  the  user-operating  system  interface  should  choose  a  uniform  inter¬ 
face  that  will  be  used  to  pass  all  arguments  to  the  operating  system  and  return 
the  results.  This  uniform  interface  will  ease  argument  access  within  the  operat¬ 
ing  system  and  simplify  the  design  of  the  stubs.  It  does  not  matter  what  the 
interface  is,  as  long  as  it  is  consistent. 


A  simple  interface,  used  in  TUNIS  for  the  MC68000,  is  to  place  all  arguments 
in  machine  registers  and  then  issue  a  system  call  specifying  the  call  number. 
This  method  works  on  the  MC68000  because  the  machine  registers  are  32  bits 
wide  and  there  are  enought  free  registers  to  hold  all  the  values  that  can  be 
passed  to  TUNIS.  Smaller  machines  may  have  trouble  handling  32  bit  numbers 
and  may  need  different  interfaces. 


TUNIS  on  the  PDP  11/23  uses  the  same  user  interface  as  UNIX  to  allow  the 
execution  of  UNIX  object  modules  on  TUNIS.  In  UNIX,  some  arguments  are  passed 
in  registers,  others  in  memory,  either  inline  after  the  system  call  or  addressed  by 
an  inline  pointer.  Thirty  two  bit  arguments  are  passed  in  a  register  pair.  For 
TUNIS,  the  lower  1  evela  of  the  o^cratiiig  syot>.,m  teiiow  a.i_iOL.n.  usci  liiCci- 

faces,  and  it  is  a  problem  to  extract  the  arguments  of  a  system  call  to  pass  them 
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down  to  the  lower  layers.  An  effort  was  made  to  localize  the  effects  of  argument 
passing,  to  make  it  easy  to  move  TUNIS  to  new  architectures. 

7.2.  Execution  of  User  Processes 

An  operating  system  will  change  protection  domains  when  dispatching  user 
processes.  This  change  will  involve  locking  the  user  process  into  memory  and 
changing  the  memory  management  registers  to  those  appropriate  to  the  user 
process.  Locking  the  user  into  memory  will  be  a  function  of  the  Memory  Manager 
that  is  machine  independent,  but  the  updating  of  the  hardware  registers  is 
machine  dependent. 

TUNIS  handles  this  problem  through  two  mechanisms.  Each  user  process  is 
controlled  by  an  envelope  that  acts  like  a  coroutine  with  the  user  process,  allow¬ 
ing  the  user  to  appear  to  be  a  Concurrent  Euclid  process.  The  RwnUser  procedure 
is  used  by  an  envelope  to  change  itself  to  a  user  process.  Because  RunUser  is 
very  machine  dependent,  it  has  been  placed  within  the  TUNIS  kernel.  RunUser  is 
passed  a  descriptor  specifying  the  user  process,  its  general  registers  and  its 
memory  mapping  registers.  RunUser  passes  control  to  the  user  process,  which 
executes  until  an  interrupt  occurs.  Then  control  is  returned  to  the  envelope  pro¬ 
cess,  along  with  enough  information  to  identify  the  cause  of  the  interrupt. 

The  envelope  does  not  call  RunUser  directly,  because  the  kernel  can  only 
execute  processes  that  are  locked  into  memory.  The  envelope  calls  the  Memory 
Manager  to  request  that  the  user  be  run,  and  the  Memory  Manager  will  lock  the 
user  into  memory  and  invoke  RunUser  to  execute  the  user  process. 

This  method  of  executing  user  processes  decreases  the  machine  dependency 
of  the  User  Manager  at  the  cost  of  placing  RunUser  into  the  kernel.  This  is  not  a 
large  cost,  as  the  actual  implementation  of  RunUser  is  likely  to  be  small. 

Interfacing  and  controlling  user  processes  are  machine  dependent  functions 
of  an  operating  system,  but  they  can  be  simplified  and  isolated  through  the  use  of 
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uniform  argument  passing  conventions  and  the  RunUser  method  of  controlling 
user  processes. 
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CHAPTER  8 


Transportation  of  TUNIS 

The  preceding  chapters  have  discussed  the  structure  of  TUNIS  and  TUNIS 
solutions  to  portability  problems.  This  chapter  examines  the  current  state  of 
TUNIS  and  summarizes  the  necessary  steps  to  transport  TUNIS  to  a  new  architec- 
ture. 

8.1.  Overview 

It  is  not  difficult  to  isolate  machine  dependent  routines  in  a  highly  structured 
operating  system.  A  structured  operating  system  is  also  simpler  to  understand, 
write,  and  test  than  an  unstructured  operating  system.  Well  defined  semantics 
for  each  module  in  the  operating  system  aid  in  the  transportation  of  the  operat¬ 
ing  system  to  a  new  architecture.  The  most  difficult  parts  of  transporting  the  sys¬ 
tem  should  be  the  rewriting  of  the  code  generator  pass  of  the  compiler  and  the 
assembly  language  kernel  supporting  concurrency.  Practice  has  shown  that  a 
new  coder  for  Concurrent  Euclid  can  be  developed  in  a  few  man-months,  and  the 
kernel  should  take  less  time  that  that. 

It  would  be  useful  to  have  the  machine  dependent  modules  of  a  portable 
operating  system  generated  from  a  specification  of  the  target  machine,  but  this 
does  not  seem  likely  at  the  present  time.  There  are  too  many  different  I/O  dev¬ 
ices  and  interfaces  that  cannot  be  easily  specified.  Interfacing  to  user  programs 
is  also  machine  dependent  and  difficult  to  specify.  The  best  that  can  be  done  now 
is  to  specify  the  modules  in  the  operating  system  that  would  have  to  be  modified, 
and  give  a  plan  for  the  modifications.  For  example,  to  add  a  new  I/O  device  to 
TUNIS,  the  I/O  driver  module  must  be  written,  and  then  the  correct  hooks  must 
be  added  to  the  file  system  to  invoke  the  new  routines. 
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8.2.  Current  State  of  TUNIS 


TUNIS  is  currently  running  on  a  PDF  11/23.  Performance  is  comparable  to 
UNIX  on  that  machine,  meaning  that  it  is  not  much  slower  that  UNIX.  TUNIS  has 
been  modified  for  the  MC68000,  and  is  currently  being  brought  up  as  a  student 
project.  The  VAX  version  of  TUNIS,  with  paging,  is  still  in  the  design  process.  All 
changes  to  implement  paging  on  the  VAX  are  hidden  in  the  Memory  Module,  except 
for  I/O  directly  into  user  memory.  The  I/O  drivers  on  the  VAX  must  have  some 
knowledge  that  the  system  is  paging  and  scatter  loading  user  programs. 

8.3.  What  Architectures  Will  TUNIS  Support? 

TUNIS  is  written  in  Concurrent  Euclid,  therefore  the  first  requirement  is  that 
Concurrent  Euclid  can  run  on  the  desired  architecture.  TUNIS  can  run  on  a  mul¬ 
tiprocessor  system  with  minimal  changes  to  the  kernel,  because  TUNIS  assumes 
that  each  process  has  a  virtual  processor  running  the  process,  independent  of 
other  processes. 

TUNIS  assumes  that  some  hardware  exists  to  protect  the  operating  system 
from  user  programs,  and  prevent  the  user  from  circumventing  the  operating  sys¬ 
tem.  This  is  not  a  strict  requirement,  and  might  not  be  true  on  a  small,  single 
user  system.  TUNIS  must  have  a  method  to  periodically  regain  control  from  user 
processes,  preferably  a  clock  interrupt.  Clock  interrupts  are  used  internally  for 
delay  timing  and  maintaining  the  time  of  day.  The  architecture  must  be  able  to 
disable  interrupts  and  support  processes  and  monitor  constructs. 

8.4.  Transporting  TUNIS  to  a  New  Architecture 

Transporting  TUNIS  to  a  new  architecture  consists  of  two  separate  problems. 
The  Concurrent  Euclid  compiler  must  be  modified  to  support  the  new  architec¬ 
ture,  and  the  machine  and  device  dependent  modules  ot  TUNIS  must  be  modified. 
The  modification  of  the  Concurrent  Euclid  compiler  should  be  straightforward 
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because  the  compiler  is  designed  to  be  portable,  and  only  the  code  generation 
pass  of  the  compiler  will  need  to  be  changed.  Changes  to  TUNIS  will  be  concen¬ 
trated  in  the  kernel.  The  other  modules  of  TUNIS  should  not  require  much 
modification. 

The  following  is  a  plan  for  transporting  TUNIS: 

Transport  the  Concurrent  Euclid  compiler. 

1 

Write  a  kernel  for  the  new  architecture  that  supports  Concurrent  Euclid 

processes  and  I/O  management  routines. 

Rewrite  the  necessary  device  controller  module  Dolo  routines. 

Modify  the  Memory  Manager  if  necessary. 

Rewrite  GetArguments  and  ReturnResults  procedures  in  the  User 

Manager,  and  machine  dependent  process  initialization  in  the  ExecCall 

procedure  in  the  User  Manager. 

With  this  simple  plan,  transporting  an  operating  system  like  TUNIS  to  a  new 
machine  should  not  be  particularly  difficult. 

8.5.  Future  Research 

TUNIS  is  now  running  on  a  PDP-11/23  computer.  TUNIS  must  be  transported 
to  another  architecture  for  the  real  test  of  a  portable  operating  system.  This  has 
not  been  done  yet,  because  it  was  felt  that  debugging  of  TUNIS  would  be  easier  on 
the  PDP-11/23,  as  UNIX  already  executes  on  that  machine.  The  next  target 
machine,  the  MC68000,  has  no  equivalent  and  usable  operating  system. 

Another  project  is  the  tuning  of  the  performance  of  TUNIS.  Execution 
profiling  of  TUNIS  should  be  done  to  determine  which  routines  are  slowest,  and 
those  routines  should  be  rewritten  to  increase  the  performance  of  TUNIS. 

A  related  problem  that  uncovered  by  the  TUNIS  project  is  the  problem  of 
debugging  operating  systems  on  bare  machines.  The  debugging  of  TUNIS  was 
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helped  by  running  the  operating  system  under  UNIX,  allowing  system  calls  to  be 
invoked,  and  the  results  displayed.  This  helped  find  many  bugs  in  TUNIS  that 
would  have  been  very  difficult  to  find  on  the  bare  machine.  Even  so,  it  took  a  lot  of 
work  to  get  TUNIS  running  on  the  PDP-11/23.  A  methodology  for  testing  a  debug¬ 
ging  a  operating  system  on  a  new  machine  should  be  developed. 
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CHAPTER  9 


Summary  and  Conclusions 


TUNIS  has  demonstrated  that  a  highly  structured,  portable  operating  system 

I 

can  be  implemented  efficiently.  It  has  also  shown  that  a  structured  version  of  the 
UNIX  operating  system  can  be  produced  and  is  practical.  Preliminary  perfor¬ 
mance  testing  of  TUNIS  has  shown  that  untuned,  TUNIS  is  30%  to  70%  slower  that 
UNIX  on  a  PDP  11/23.  This  is  better  than  was  originally  expected,  and  careful  tun¬ 
ing  of  the  critical  sections  should  enable  TUNIS  to  match  the  performance  of 
UNIX. 

TUNIS  also  demonstrates  that  monitors  are  a  viable  tool  for  operating  sys¬ 
tem  implementation,  and  that  Concurrent  Euclid  is  a  useful  language  for  the 
implementation  of  a  portable  operating  system.  The  only  parts  of  TUNIS  that 
could  not  be  written  in  Concurrent  Euclid  were  several  memory  copying  routines 
that  had  to  access  more  than  the  64K  address  space  of  the  PDP  11.  Concurrent 
Euclid  versions  of  these  routines  will  be  used  for  other  TUNIS  implementations. 

The  verification  of  the  modules  of  TUNIS  has  not  proceeded  at  the  same  pace 
as  the  implementation.  The  Cache  module  is  currently  being  verified,  but 
verification  of  the  other  modules  has  not  been  attempted.  Verification  is  a 
difficult  problem  when  attempting  to  verify  large,  complex  modules,  as  the 
specifications  are  harder  to  define.  Additionally,  the  necessity  to  handle  device 
errors  and  user  errors  complicate  the  specifications. 
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Overall,  TUNIS  has  been  a  successful  implementation  of  a  portable  operating 
system  in  a  high  level,  structured  language.  More  work  will  be  needed  to  tran¬ 
sport  TUNIS  to  another  architecture  and  verify  that  there  are  no  machine  depen¬ 
dencies  in  the  machine  independent  portions  of  TUNIS. 
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Postscript 


Other  research  on  the  Tunis  project: 

Briscoe,  Harold  E.,  Memory  Management  on  Paging  Hard'ware:  An  Erperi- 
ment  Involving  Tunis  and  the  Vax,  M.  Sc.  Thesis,  1982,  University  of  Toronto. 

Holt,  R.  C.,  Concurrent  Euclid,  Unix,  and  Tunis  Addison-Wesley  1983. 

Perelgut,  S.,  Structured  Device  Management,  M.  Sc.  Thesis,  expected  1983, 
University  of  Toronto. 
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